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Description 

[0001] The present invention relates to the fields of 
distributed computing systems, client-server computing 
and object oriented programming. 5 
[0002] Specifically, the present invention relates to a 
method and apparatus for providing program mecha- 
nisms which allow generic stubs to marshal and unmar- 
shal data in object-reference-specific data formats. 
[0003] A key problem in modern object oriented dis- 
tributed processing systems is permitting object appli- 
cations to communicate with a new object request bro- 
ker ("ORB") which has its own unique data format, with 
only minor modification to the supporting code mecha- 
nisms. Similarly client applications and stubs should be 
able to communicate seamlessly with different ORBs in 
a system which can communicate with a multiplicity of 
ORBs wherein each of the ORBs has its own unique 
data format. 

[0004] For example, the Object Management Group 
(OMG) is an industry standards organization that is cre- 
ating multi-vendor standards for distributed object-ori- 
ented programming. One of the cornerstones of the 
OMG work has been the definition of a common Inter- 
face Definition Language, known as IDL, that is now in 
widespread use as a standard way for defining interfac- 
es to network objects in a way that is independent of the 
particular network protocols that are being used or the 
particular programming languages that are being used 
by the clients and the servers. 

[0005] The IDL language is object-oriented and sup- 
ports multiple inheritance. It comes with a rich set of 
built-in primitive types (such as floats, booleans, etc.) 
and also defines a set of structured types including 
structs, unions and sequences. 

[0006] The Object Management Group standardized 
on the IDL interface definition language as a uniform 
way of defining interfaces to network objects. However, 
the OMG initially left the on-the-wire protocol and data 
formats undefined. As a result different vendors imple- 
mented ORBs with different protocols and different data 
formats. 

[0007] Recently, the OMG has agreed on a common 
ORB inter-operability protocol, the Universal Networked 
Objects (UNO) protocol. However this is primarily 
viewed as a gateway protocol for connecting object sys- 
tems from different vendors. At least in the short term 
different vendors appear likely to continue to use their 
existing protocols for higher performance within their 
own object systems, while supporting lower perform- 
ance UNO gateways to other ORBs. Thus a current 
need exists to permit object applications to transparently 
communicate with these ORBs with different protocols 
and different data formats. 

[0008] For further description of object oriented de- 
sign and programming techniques see "Object-oriented 
Software Construction" by Bertrand Meyer, Prentice- 
Hall 1988. For further information on OMG, CORBA, 



ORBs and IDL see the "Common Object Request Bro- 
ker: Architecture and Specification", Revision 2.0, July 
1965. 

[0009] Currently Internet browsers are very limited in 
their ability to interact with network servers. Typically a 
browser such as Mosaic will down-line load an HTML 
document and then wait passively for a human user to 
either select another document or to enter HTML forms 
information that can be passed back to the server. 
[001 0] Two new developments are promising to make 
the Internet a more dynamic environment. The first is 
support for scripting languages in Internet browsers 
(such as the Sun Microsystems, Inc. (SUN) JAVA lan- 
guage described below) so that a browser can download 
and execute interactive scripts. This transforms brows- 
ers from being passive viewers into being dynamic 
agents that can interact with the Internet on a user's be- 
half and display rapidly changing information. The sec- 
ond development is the widespread adoption of the Ob- 
ject Management Group's distributed object interfaces 
based on the IDL interface definition language. These 
provide a standard way for network servers to export 
services as "network objects" in a language and vendor 
independent way. This will make it much easier to build 
network services that can be transparently accessed 
from different client environments. 
[0011] EP-0604010 discloses an apparatus and a 
method comprising a logic module called a sub-con- 
tract, that has been designed to provide control of the 
basic mechanisms of object invocation and argument 
passing that are most important in distributed systems, 
in a way which makes it easy for object implementors to 
select and use an existing sub-contract, and which per- 
mits the application programmers to be unaware of the 
specific sub-contracts that are being used for particular 
objects. 

[0012] It includes a new type of object, termed a 
"spring object", which includes a method table, a sub- 
contract mechanism and a data structure which repre- 
sents the subcontract's local private state. 
[001 3] Each subcontract contains a client-side portion 
and a related server-side portion. Each object type has 
an associated subcontract The client-side portion of a 
subcontract has the ability to generate a new spring ob- 
ject, to delete a spring object, to marshal information 
about its associated object into a communications buff- 
er, to unmarshal data in a communications buffer which 
represents its associated object, to transmit a commu- 
nications buffer to its associated server-side subcon- 
tract, which includes either transmitting an object from 
one location to another or transmitting a copy of an ob- 
ject from one location to another. The server-side por- 
tion of the subcontract mechanism includes the ability 
to create a spring object, to provide support for process- 
ing incoming calls and related communications buffers 
and to provide support for revoking an object. 
[001 4] It also includes methods for using subcontracts 
to process object invocations, including the passing of 
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arguments, which arguments may themselves be ob- 
jects, in a distributed computing system, wherein the cli- 
ent applications may be on different computers from the 
object implementations. 

[0015] EP-0643349 discloses an apparatus and a 5 
method comprising logic modules, called a client-side 
stub generator, a database of compressed client-side 
stub execution code and a client-side stub interpreter, 
that have been designed to minimize the memory space 
required by client-side stubs while retaining the design 
of stubs to provide control of the basic mechanisms of 
object invocation and argument passing that are most 
important in distributed systems, and which permits the 
application programmers to be unaware of the specific 
stubs that are being used for particular objects. 
[0016] The mechanism used to reduce this memory 
space comprises a stub generator (called "CONTOCC") 
for generating a data base of compressed client-side 
stub description filed which are stored in computer 
memory and a stub-interpreter which knows how to read 
these client-side stub description files. CONTOCC 
reads interface definition language ("IDL") files and gen- 
erates corresponding C++ files. CONTOCC has the abil- 
ity to read the IDL data and generate either uncom- 
pressed C++ stub files or the special compressed client- 
side stub interpreter files which contain only those data 
that are unique to the particular stub method involved in 
byte coded form 

[0017] The stub interpreter logic module receives a 
target object, arguments related to the particular stub 
method called and a pointer to the compressed byte 
code representations of the stub code in the data base 
of compressed client-side stub description files which 
are stored in computer memory, and proceeds to exe- 
cute the object invocation, marshaling or unmarshaling 
of any return messages as required. 

Java 

[0018] Java is a strongly typed object-oriented lan- 
guage with a C like syntax. The Java compiler and run- 
time code mechanisms enforce type safety so that there 
can be no wild pointers or other references that violate 
the language's type system. So for example, there is no 
"void*" and all casts are validated at runtime. 
[001 9] The Java language is typically compiled to ma- 
chine-independent byte-codes and then a Java virtual 
machine interprets those byte codes in order to execute 
the Java program. Java can be integrated into network 
HTML browsers, so that as part of viewing a document 
one can down-line load a set of Java byte-codes and 
then execute them on the client machine. Because Java 
is completely typesafe the client browser can feel con- 
fident that the Java program can be executed safely 
without endangering the security or integrity of the client 
Java is more fully described in The Java Language 
Specification" release 1.0 Alpha3, by Sun Microsys- 
tems, Inc. dated May 11, 1995. 



[0020] Scripted language systems like Java generate 
Java programs that are designed to be portable and to 
be deployed in a variety of different environments. It is 
therefore desired to allow Java programs to use different 
ORBs without requiring any changes to the Java pro- 
gram. Because the generated stubs are part of the Java 
program it is necessary that the stubs be ORB-inde- 
pendent so that the Java program and its associated 
stubs might be used in any of a multiplicity of ORBs. 
[0021] This disclosure describes a solution to the ba- 
sic problem by creating a generic interface between the 
stubs and ORB specific data mechanisms. These ORB 
specific data mechanisms include one or more Marshal- 
Buffer Objects which have methods for marshaling and 
unmarshaling one or more particular ORB related on- 
the-wire data formats and a method and apparatus for 
using an object reference (Objref) to indicate the partic- 
ular MarshalBuffer Object to use for this particular Ob- 
ject call. 

[0022] The present invention provides an elegant and 
simple way to provide mechanisms for invocation of ob- 
jects by client applications and for argument passing be- 
tween client applications and object implementations, 
without the client application or the operating system 
knowing the details of how these mechanisms work. 
Moreover, these mechanisms functions in a distributed 
computer environment with similar ease and efficiency, 
where client applications may be one computer node 
and object implementations on another. 
[0023] In one aspect of the invention, there is provided 
a computer system having a processor, a memory, a dis- 
play device, an input/output device, and an operating 
system (OS) for processing program code mechanism 
invocations which are directed to one of a multiplicity of 
remote Object Request Brokers (ORBs), characterised 
in that the computer system further comprises: 

an ORB independent layer of code mechanisms in- 
cluding program applications and related stubs; and 
an ORB dependent layer of code mechanisms, cou- 
pled to the ORB independent layer, the ORB de- 
pendent layer comprising 

program code mechanisms which are ORB- 
specific and which are configured to generate 
a marshal code mechanism to marshal data in 
an ORB required format, and 
program code mechanisms configured to use 
a specific network protocol code whereby a pro- 
gram application code mechanism from the 
ORB independent layer can invoke a call on a 
remote implementation program code mecha- 
nism and the ORB-specific program code 
mechanisms in the ORB dependent layer will 
determine an appropriate marshal code mech- 
anism to marshal data in an ORB required for- 
mat; 

thereby providing a computer system capable 
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of communicating with a multiplicity of ORBs 
wherein each ORB requires data to be in a spe- 
cific format. 

[0024] In another aspect of the invention there is pro- 
vided a method of operating a computer system having 
a processor, a memory, a display, an input/output mech- 
anism, an operating system and at least one client ap- 
plication program, one or more stub programs related 
to the client application, the method performed by the 
computer being characterised by the steps of: 



nisms configured to use a specific network protocol 
code whereby a program application code mecha- 
nism from the ORB independent layer can invoke a 
call on a remote implementation program code 

5 mechanism and the ORB-specific program code 
mechanisms in the ORB dependent layer will deter- 
mine an appropriate marshal code mechanism to 
marshal data in an ORB required format, thereby 
providing a computer system capable of communi- 

io eating with a multiplicity of ORBs wherein each 
ORB requires data to be in a specific format. 



invoking a call on a program implementation code 
mechanism, the call invocation being made by a cli- 
ent application wherein the call includes a reference 
to the program implementation code mechanism; 
using a stub program code mechanism which is re- 
lated to the client application to receive the call in- 
vocation, wherein the stub program code mecha- 
nism has no knowledge of a format required for mar- 
shaling data provided by the client application in 
connection with the call invocation; 
calling a first specific program code mechanism by 
the stub program code mechanism, requesting the 
first specific program code mechanism to provide a 
MarshalBuffer code mechanism that knows how to 
format data provided by the client application in con- 
nection with the call invocation; 
marshaling the data provided by the client applica- 
tion in connection with the call invocation, the mar- 
shaling being done by the stub program code mech- 
anism using the MarshalBuffer code mechanism; 
and 

sending the call invocation to a server containing 
the program implementation code mechanism 
which is the target of the call. 

[0025] In yet another aspect of the invention there is 
provided a computer program product comprising a 
computer system usable storage medium having com- 
puter readable code embodied therein for causing a 
computer system to process program code mechanism 
invocations which are directed to one of a multiplicity of 
remote Object Request brokers (ORBs), the computer 
program product being characterised by: 

a first computer readable program code mechanism 
configured to comprise an ORB-independent layer 
of code mechanisms including client applications 
and related stub program code mechanisms; and 
a second computer readable program code mech- 
anism configured to comprise an ORB dependent 
layer of code mechanisms coupled to the ORB in- 
dependent layer, the ORB dependent layer com- 
prising program code mechanisms which are ORB- 
specific and which are configured to generate a 
marshal code mechanism to marshal data in an 
ORB required format and program code mecha- 



[0026] The present invention will now be further de- 
scribed, by way of example, with reference to the ac- 
companying drawings, in which:- 

Figure 1 illustrates the configuration of a typical 
computer hardware system used with and as a part 
of the present invention. 

Figure 2 illustrates the prior art relationship of client 
and server applications to stubs and network soft- 
ware. 

Figure 3 illustrates a system showing Java ORB 
classes. 

Figure 4 illustrates the relationship between stub 
objects, ORB specific code/subcontract mecha- 
nisms, and server application objects in a single 
ORB system. 

Figure 5 illustrates remote object invocation using 
ORB specific code/subcontracts, ORB-specific 
Marshall Buffer mechanisms in a multi-ORB system. 
Figure 6 illustrates an exemplary Marshall Buffer 
code mechanism. 

Figure 7 illustrates a more specific remote object 
invocation using ORB specific code/subcontracts, 
ORB-specific MarshalBuffer mechanisms in a mul- 
ti-ORB system. 

NOTATIONS AND NOMENCLATURE 

[0027] The detailed descriptions which follow may be 
presented in terms of program procedures executed on 
a computer or network of computers. These procedural 
descriptions and representations are the means used 
by those skilled in the art to most effectively convey the 
substance of their work to others skilled in the art. 
[0028] A procedure is here, and generally, conceived 
to be a self-consistent sequence of steps leading to a 
desired result. These steps are those requiring physical 
manipulations of physical quantities. Usually, though not 
necessarily, these quantities take the form of electrical 
or magnetic signals capable of being stored, trans- 
ferred, combined, compared, and otherwise manipulat- 
ed. It proves convenient at times, principally for reasons 
of common usage, to refer to these signals as bits, val- 
ues, elements, symbols, characters, terms, numbers, or 
the like, it should be noted, however, that all of these 
and similar terms are to be associated with the appro - 
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priate physical quantities and are merely convenient la- 
bels applied to these quantities. 

[0029] Further, the manipulations performed are often 
referred to in terms, such as adding or comparing, which 
are commonly associated with mental operations per- 5 
formed by a human operator. No such capability of a 
human operator is necessary, or desirable in most cas- 
es, in any of the operations described herein which form 
part of the present invention; the operations are ma- 
chine operations. Useful machines for performing the 
operations of the present invention include general pur- 
pose digital computers or similar devices. 
[0030] The present invention also relates to appara- 
tus for performing these operations. This apparatus may 
be specially constructed for the required purposes or it 
may comprise a general purpose computer as selective- 
ly activated or reconfigured by a computer program 
stored in the computer. The procedures presented here- 
in are not inherently related to a particular computer or 
other apparatus. Various general purpose machines 
may be used with programs written in accordance with 
the teachings herein, or it may prove more convenient 
to construct more specialized apparatus to perform the 
required method steps. The required structure for a va- 
riety of these machines will appear from the description 
given. 

[0031] The following disclosure describes solutions to 
the problems which are encountered by object oriented 
systems designers when attempting to implement 
schemes for object invocation and for argument passing 
in distributed systems wherein the arguments may be 
objects, in ways which do not lock the object oriented 
base system into methods which may be difficult to 
change at a later time. Moreover, the invention disclosed 
describes a "Marshal Buffer mechanisnf which con- 
tains operations (called "methods " in Object Oriented 
programming parlance) for marshaling data for a spe- 
cific ORB; a "MulthORB Marshaling system" which 
permits a client application and related stub to invoke 
an operation on a target object without any knowledge 
or concern about which ORB this target object uses or 
what data formate the ORB requires for the arguments 
of the operation invoked; and a "Computer system for 
multi-ORB communication" comprising an ORB inde- 
pendent layer which contains client applications and 
stubs; an ORB dependent-OS independent layer which 
contains ORB dependent code/Subcontract code 
mechanisms as well as ORB specific MarshalBuffers for 
a multiplicity of ORBs; and an Operating System (OS) 
layer. The "ORB dependent code mechanism" used 
in the present invention, is analogous to the "subcon- 
tract mechanism "which is associated with each object 
and which is described in EP-A-0 604 010. 
[0032] In the following description, for purposes of ex- 
planation, specific data and configurations are set forth 
in order to provide a thorough understanding of the 
present invention. The preferred embodiment described 
herein is implemented as a portion of the SPRING-DIS- 



TRIBUTION Object-Oriented Operating System creat- 
ed by Sun Microsystems®, Inc. (Sun Microsystems is a 
registered trade mark of Sun Microsystems, Inc.). How- 
ever, it will be apparent to one skilled in the art that the 
present invention may be practised without the specific 
details and may be implemented in various computer 
systems and in various configurations, or makes or 
models of tightly-coupled processors or in various con- 
figurations of loosely-coupled multi processor systems. 
The Spring-Distribution Object-Oriented Operating Sys- 
tem is described in M A Spring Collection" A Collection of 
Papers on the Spring distributed Object-Oriented oper- 
ating System published September 1994 by Sun Mi- 
crosystems, Inc.. 

Operating Environment 

[0033] The environment in which the present inven- 
tion is used encompasses the general distributed com- 
puting system, wherein general purpose computers, 
workstations, or personal computers are connected via 
communication links of various types, in client-server ar- 
rangement, wherein programs and data, many in the 
form of objects, are made available by various members 
of the system for execution and access by other mem- 
bers of the system. Some of the elements of a general 
purpose workstation computer are shown in Figure 1 , 
wherein a processor 1 is shown, having an Input/Output 
("I/O") section 2, a central processing unit ("CPU") 3 and 
a memory section 4. The I/O section 2 is connected to 
a keyboard 5, a display unit 6, a disk storage unit 9 and 
a CD-ROM drive unit 7. The CD-ROM unit 7 can read a 
CD-ROM medium 8 which typically contains program 
code mechanisms 10 and data. 

Stubs 

[0034] Techniques for providing a language-level ve- 
neer for remote operations (for example, "Remote Pro- 
cedure Calls") have been in use for many years. Typi- 
cally these take the form that a remote interface is de- 
fined in some language. Then a pair of stubs are gen- 
erated from this interface. The client stub runs in one 
machine and presents a language level interface that is 
derived from the remote interface. The server stub runs 
in some other machine and invokes a language-level in- 
terface that is derived from the remote interface. Refer- 
ring now to Figure 2, to perform a remote operation, a 
client application 12 on one machine 11, invokes the 
chent stub 1 4, which marshals the arguments associat- 
ed with the invocation into network buffer(s) and trans- 
mits them to the server stub 22 on the remote machine 
18, which un marshals the arguments from the network 
buffer(s) and calls the server application 24. Similarly, 
when the server application 24 returns a response, the 
results are marshaled up by the server stub 22 and re- 
turned to the client stub 14, which unmarshals the re- 
sults and returns them to the client application 12. The 
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entire mechanics of argument and result transmission, 
and of remote object invocation, are performed in the 
stubs. Both the client application and the server appli- 
cation merely deal in terms of conventional language- 
level interfaces. 

[0035] When the arguments or results are simple val- 
ues such as integers or strings, the business of marshal- 
ing and unmarshaling is reasonably straightforward. 
The stubs will normally simply put the literal value of the 
argument into the network buffer. However, in languag- 
es that support either abstract data types or objects, 
marshalling becomes significantly more complex. One 
solution is for stubs to marshall the internal data struc- 
tures of the object and then to un marshal this data back 
into a new object This has several serious deficiencies. 
First, it is a violation of the "abstraction" principle of ob- 
ject-oriented programming, since stubs have no busi- 
ness knowing about the internals of objects. Second, it 
requires that the server and the client implementations 
of the object use the same internal layout for their data 
structures. Third, it may involve marshalling large 
amounts of unnecessary data since not all of the internal 
state of the object may really need to be transmitted to 
the other machine. An alternative solution is that when 
an object is marshalled, none of its internal state is trans- 
mitted. Instead an identifying token is generated for the 
object and this token is transmitted. For example in the 
Eden system, objects are assigned names and when an 
object is marshalled then its name rather than its actual 
representation is marshalled. Subsequently when re- 
mote machines wish to operate on this object, they must 
use the name to locate the original site of the object and 
transmit their invocations to that site. This mechanism 
is appropriate for heavyweight objects, such as files or 
databases, but it is often inappropriate for lightweight 
abstractions, such as an object representing a cartesian 
coordinate pair, where it would have been better to mar- 
shal the real state of the object. Finally, some object- 
oriented programming systems provide the means for 
an object implementation to control how its arguments 
are marshalled and unmarshalled. For example, in the 
Argus system object implementors can provide func- 
tions to map between their internal representation and 
a specific, concrete, external representation. The Argus 
stubs will invoke the appropriate mapping functions 
when marshalling and unmarshaling objects so that it is 
the external representation rather than any particular in- 
ternal representation that is transmitted. These different 
solutions all either impose a single standard marshalling 
policy for all objects, or require that individual object im- 
plementors take responsibility for the details of marshal- 
ling. An advanced object marshaling process is de- 
scribed in the above referenced EP-A-0 604 010 which 
describes "Subcontracts." 



Current Problem Summary 

Specific Problem for Current Object Oriented 
Systems 

5 

[0036] The specific problem here is that different 
ORBs have different on-the-wire data formats. So one 
ORB might marshal bytes in little-endian order, another 
in big-endian, etc. Different ORBs also have different 

10 on-the-wire formats for arrays, strings, unions, etc. 
[0037] So it is desirable to have ORB independent 
stubs that can marshal their data differently when talking 
to different objects. Thus, one might use a DEC data 
format when talking to a DEC object and a Sun datafor- 

15 mat when talking to a Sun object. And it is desirable for 
one to allow a single set of stubs to be in simultaneous 
use with different ORBs. 

Proposed Solution to the Problem 

20 

[0038] The solution is; 

(1) define a generic interface for marshalling. This 
generic interface provides methods for marshalling 

25 and unmarshalling ints, shorts, bytes, chars, and 
strings. But it says nothing about how these meth- 
ods are implemented. 

(2) Different ORBs provide their own implementa- 
30 tion of the generic marshal buffer interface. As well 

as supporting the generic marshalling and unmar- 
shalling methods, these ORB specific marshal 
classes may provide additional methods for mar- 
shaling ORB specific data. For example the Spring 
35 ORB implementation of MarshalBuffer provides 
methods for marshalling and unmarshalling Spring 
doors. 

(3) Each object reference (Objref) contains a point- 
40 er to a set of ORB runtime machinery that belongs 

to the ORB that implements that object. In the pre- 
ferred implementation this consists of a pointer to 
the client side ORB-dependent code mechanism/ 
subcontract for the object. 

45 

(4) The ORB runtime machinery described in (3) will 
support a method for obtaining a MarshalBuffer ob- 
ject. The runtime machinery will return a Marshal- 
Buffer object that implements the correct marshai- 

50 ling and unmarshalling for that ORB. 

(5) The generic stubs work entirely in terms of the 
generic MarshalBuffer interface. 

55 (6) At the beginning of each call, the generic stubs 
call into the ORB specific runtime code mecha- 
nisms associated with the object reference to get 
an appropriate MarshalBuffer object. The stubs 
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then use the generic marshalling and unmarshalling 
interfaces to marshal and un marshal data to and 
from that MarshalBuffer object. Since the imple- 
mentations of these marshal and unmarshal meth- 
ods are ORB specific, this means that the data is 
being marshalled and unmarshalled in an ORB spe- 
cific way. 

[0039] In the currently preferred embodiment, the ge- 
neric MarshalBuffer includes additional capabilities for 
handling differences in several known ORBs. For exam- 
ple, 

(a) in addition to methods for marshalling and unmar- 
shalling simple data types, the generic MarshalBuffer 
provides a way for Marshalling array descriptors. This 
method takes the bounds of the array and then marshals 
an array descriptor in an ORB specific way. For exam- 
ple, the DOE O RB code marshals the length of the array. 
But the Spring ORB code marshals the lower bound and 
the upper bound, and (b) similarly provides mechanisms 
for unmarshalling an array descriptor 

HOW TO MAKE AND USE THE INVENTION 

A Portable ORB Implementation 

[0040] One of the goals for the preferred embodiment 
of the present invention is for the Java ORB implemen- 
tation to be allowed to work directly with a variety of dif- 
ferent on-the-wire protocols and data formats. In partic- 
ular, a single Java program must be able to simultane- 
ously use object references that refer to objects in dif- 
ferent ORBs. The internet is a very heterogeneous en- 
vironment and it is desired not to restrict Java IDL clients 
to only working with a single server at a time. 
[0041] In particular the Java ORB implementation of 
the preferred embodiment must be able to communicate 
directly with both Sun's Distributed Object Environment 
(DOE)and with the Spring distributed operating system. 
It is also desired to design the Java ORB core so that it 
could communicate with UNO gateways or with DCE 
based object systems. 

Portability issues 

[0042] Portability is an issue at several different lev- 
els. 

[0043] At the lowest level, Java's socket class is used 
to get machine and OS independent access to the IP 
protocol family. 

[0044] At the next level up, different ORBs use differ- 
ent low-level network transport protocols. For example, 
Sun's DOE systems uses ONC RPC, the Spring system 
uses an optimized sequenced packet protocol, UNO us- 
es TCP/IP, some other vendors use DCE RPC, etc. 
However, while this may seem like fairly major differ- 
ence it is actually comparatively easy to plug in different 
low level transport protocols. 



[0045] Unfortunately, the different transport protocols 
also come with different data formats for simple data 
types. For example, integer values may have to be 
transmitted in big-endian byte order for an ONC ORB 

s and in little-endian byte order for a DCE ORB. This af- 
fects the way that one can marshal and unmarshal ar- 
guments from the marshal buffers. 
[0046] At the next level up, even if two ORBs agree 
on a standard format for simple data types, they may 

10 disagree on how to handle the IDL structured data types. 
For example both the Spring ORB and the DOE ORB 
use the ONC XDR format for simple data types, but 
when they transmit an array descriptor the DOE ORB 
simply transmits an integer specifying the length, where- 

15 as the Spring ORB transmits two integers, one specify- 
ing the array's lower bound and the other specifying the 
array's upper bound. This means that if one wants to 
have stubs that can be used between different ORBs 
then the stubs can't directly marshal things like array de- 

20 scriptors, but instead must call into some ORB specific 
code. 

[0047] Finally there are likely to be different formats 
for the various kinds of IDL related meta-data, such as 
object references, method identifiers, exception identi- 
25 fiers, and type identifiers. For example, Spring uses in- 
tegers as method identifiers. Other ORBs send either a 
simple method name of a fully qualified interface name 
plus method name combination. 



[0043] In the preferred embodiment, the general strat- 
egy has been to create stubs that are ORB independent 
and to conceal the ORB dependencies inside the indi- 

35 vidual object references. This has the major advantage 
that a single Java stub compiler can be used that can 
generate stubs that can be used with any ORB. Howev- 
er this means that there must be interfaces between the 
stubs and the object reference that allow the stubs to 

40 marshal arguments and invoke remote operations in an 
ORB independent manner. 

[0049] Experience with using the subcontract mech- 
anism in the Spring system was used in designing the 
separation between the stubs and the ORB specific lay- 

45 er. Spring permits different object references to have dif- 
ferent formats and to have different invocation mecha- 
nisms, so as to be able to support things like replication 
and data caching. It does this by associating a software 
module called a subcontract with each object reference. 

50 When the Spring stubs want to marshal or invoke an 
object reference, they call into the subcontract associ- 
ated with the object reference, so that the marshalling 
or object invocation is performed in a way that is appro- 
priate to that subcontract. 

55 [0050] In the JAVA ORB implementation of the pre- 
ferred embodiment one extra abstract interface was 
added so that a single set of stubs could communicate 
with multiple ORBs. An abstract MarshalBuffer interface 
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was added and the creation of MarshalBuffers was 
moved from the stubs into the subcontracts, so that dif- 
ferent ORBs could provide different sub-classes of Mar- 
shal Buffer which marshalled and unmarshalled data in 
the correct format for that ORB. Figure 3 provides an 5 
illustration of the JavaORB classes. In Figure 3, A Java- 
Application 70 uses a set of stubs 68 to talk to a set of 
remote objects (not shown). These stubs and applica- 
tions comprise an "ORB Independent" layer 69 which 
interface generically with the "OS Independent/ORB de- 
pendent" layer 61. An exemplary "OS Independent/ 
ORB dependent" layer 61 comprises, for example, two 
different Spring subcontract mechanisms 66, 64 that 
use the same MarshalBuffer 60 and the same Spring 
network protocol code mechanism 56 to talk to the re- 
mote object (not shown). An ORB dependent code 
mechanism 62 for use by Sun's DOE ORB is shown, 
which uses a DOE MarshalBuffer 58 which in turn uses 
the DOE network protocol code mechanism 54. In this 
example, both the Spring network protocol code mech- 
anism 56 and the DOE network protocol code mecha- 
nism 54 use the Java network "Socket" code mecha- 
nism 52. (The Java "Socket" class provides access to 
TCP/IP and UDP functionality in a way that is broadly 
similar to the sockets interfaces provided in the Berkeley 
UNIX distributions.). This Java network "Socket" code 
mechanism 52 uses Operating System (OS) services 
51 from whatever OS it is running on. 

The MarshalBuffer interface 

[0051] In the preferred embodiment the interface be- 
tween the stubs and the MarshalBuffer interface was de- 
fined so that the stubs not only marshal simple primitive 
types such as char and long, but are also given control 
over how structured IDL data types were marshalled. 
This meant providing generic MarshalBuffer methods 
for marshalling and unmarshalling array headers and 
union discriminators. 

Putting the pieces together 

[0052] In the context of the present invention different 
applications may call objects or send data to objects 
which have implementations that are associated with 
different ORBs but in this case using ORB- independent 
code/subcontract mechanisms to determine the target 
ORB, to find a MarshalBuffer that knows how to marshal 
the data for the target implementation and to communi- 
cate with the machine containing the target implemen- 
tation. Referring now to Figure 5. the client application 
112 again issues the call on stub 112. In this instance 
however, the stub 112 sends the call to an ORB-specific 
code/subcontract mechanism 212 determined in the 
preferred embodiment by an indication in the objref. (An 
alternative embodiment would include some ORB- ID 
mechanism for identifying the ORB-specific code mech- 
anism required by a specific object call, where this ORB- 



ID mechanism might be specified when the object im- 
plementation is created and used each time this object 
is called thereafter. Those skilled in the art will recognize 
that there are many ways to identify the ORB-specific 
code required by an Object reference.) This ORB-spe- 
cific code/subcontract mechanism 212 determines what 
format is required by the target ORB and provides a Mar- 
shalBuffer Object 210 capable of doing the correct mar- 
shaling, notifying the client stub 114 of which Marshal- 
Buffer Object 21 0 is to be used. The client stub 1 1 4, us- 
ing this MarshalBuffer Object 21 0 marshals the data and 
sends it to the network software code mechanism/de- 
vice 116 as before. On the server side 118 the target 
ORB-specific code mechanism 214 knows how to un- 
marshal the data and passes it to the Unmarshal Buffer 
216 which in the case of a Java transmission may be a 
virtual machine to interpret the byte-code data for exe- 
cution by the server machine. 

[0053] In the preferred embodiment, for any IDL ob- 
ject reference of type FOO, we provide a Java stub class 
FOO that consists of a set of stub methods and pointer 
to a subcontract object that contains information identi- 
fying the server object. Each object of the stub class will 
point to a different subcontract object, and these sub- 
contract objects may have different implementations, al- 
lowing them to talk to different ORBS. When the stub 
methods wish to make an object invocation they ask the 
subcontract to give them a suitable MarshalBuffer object 
and then use that MarshalBuffer to marshal the argu- 
ments and unmarshal the results. An exemplary Mar- 
shalBuffer is shown in Figure 6. The MarshalBuffer in- 
terface shown in Figure 6 represents a clean separation 
between the functionality of the ORB dependent code 
in marshaling and unmarshalling data. The stubs under- 
stand the particular set of arguments or results that arc 
required for a particular IDL call. The stubs then call into 
the ORB dependent code mechanism that implements 
the MarshalBuffer interface in order to marshal (or un- 
marshal) each data item contained in the arguments or 
results. The ORB dependent code mechanism knows 
nothing about the IDL interface but simply marshals 
each data item in the correct format for that target ORB. 
Key concepts in the preferred embodiment are that (I) 
the MarshalBuffer interface such as shown in Figure 6 
is an interface which different ORBs can provide their 
own implementation for, and (2) the ORB dependent 
code provides the MarshalBuffer object to the stubs. 
[0054] So for example, referring now to Figure 7 an 
object reference of IDL type FOO 404 that points at a 
Spring server (not illustrated) might use Spring's Single- 
ton subcontract 408. When the stubs for FOO 406 come 
to make a call on one of the FOO methods they f irst ask 
the subcontract 408 to give them a MarshalBuffer. The 
Singleton subcontract 408 will return a Spring Marshal- 
Buffer 41 0 that will obey the Spring on-the-wire data for- 
mats. The stubs 406 then marshal the method argu- 
ments into that marshal buffer 410. After the stubs 406 
have marshaJled all the arguments, they call into the 
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Subcontract 408 to actually transmit the method invo- 
cation to the server. The Singleton subcontract 408 uses 
the Spring network protocol handlers 41 2 to transmit the 
request to the Spring server and get the results. The 
stubs 406 can them unmarshal the results from the Mar- 
shalBuffer 41 0 and return them to the client application 
402. 

[0055] In the preferred embodiment, a stub compiler 
contojava that generates complete Java client stubs for 
IDL interfaces is used. 

[0056] In addition, a working Java ORB implementa- 
tion that can communicate with both DOE and Spring 
servers is used. The code for talking to Spring includes 
two subcontracts (Caching and Singleton) and a Java 
implementation of Spring's proxy-proxy protocol. The 
code for talking to DOE includes a single subcontract 
(for the Basic Object Adapter (BOA)) and code for locat- 
ing and activating DOE BOA objects. All of this ORB 
code is written in Java and is portable between different 
Java environments. It is believed that this ORB core 
could be easily extended with subcontracts that could 
talk to UNO or to ORBs implemented by other vendors. 



Claims 

1 . A computer system having a processor (3), a mem- 
ory (4), a display device (6), an input/output device 
(2), and an operating system (OS) for processing 
program code mechanism (1 0) invocations which 
are directed to one of a multiplicity of remote Object 
Request Brokers (ORBS), characterised in that 
the computer system further comprises: 

an ORB independent layer of code mecha- 
nisms (69) including program applications and 
related stubs; and 

an ORB dependent layer of code mechanisms 
(61 ), coupled to the ORB independent layer, the 
ORB dependent layer comprising 

program code mechanisms which are 
ORB-specific (212) and which are config- 
ured to generate a marshal code mecha- 
nism (210) to marshal data in an ORB re- 
quired format, and 

program code mechanisms configured to 
use a specific network protocol code (116) 
whereby a program application code 
mechanism from the ORB independent 
layer can invoke a call on a remote imple- 
mentation program code mechanism and 
the ORB-specific program code mecha- 
nisms in the ORB dependent layer (61 ) will 
determine an appropriate marshal code 
mechanism to marshal data in an ORB re- 
quired format; 

thereby providing a computer system ca- 



pable of communicating with a multiplicity 
of ORBs wherein each ORB requires data 
to be in a specific format. 

5 2. A computer system as defined in claim 1 , wherein 
the ORB independent layer of code mechanisms 
(69) including program applications and related 
stubs comprise object applications and related 
stubs. 

10 

3. A computer system as defined in claim 1 or 2, 
wherein the marshal code mechanism (210) to mar- 
shal data in an ORB required format which is locat- 
ed in the ORB-dependent layer (61) is a Marshal- 

is Buffer Object configured to execute operations to 
marshal data in an ORB specific format. 

4. A computer system as defined in claim 1 , 2 or 3, 
wherein the program code mechanism configured 

20 to use a specific network protocol code (1 1 6) com- 
municates with a server computer (118) comprising: 

a receiving program code mechanism (120) 
comprising ORB dependent code configured to 

25 receive an object invocation from a remote 

computer system (110); and 
an ORB independent server application where- 
by the receiving program code mechanism 
calls into the ORB independent server applica- 

30 tion (214), passing in a MarshalBuffer that al- 

lows the server application to unmarshal argu- 
ments and marshal results without having to 
know which ORB a call came from. 

35 5. A computer system a defined in claim 1,2,3 or 4, 
wherein the ORB-dependent layer (61 ) is also inde- 
pendent of the Operating System (OS) layer. 

6. A method of operating a computer system having a 
40 processor (3) , a memory (4) , a display (6) , an imput/ 
output mechanism (2), an operating system and at 
least one client application program (112), one or 
more stub programs (114) related to the client ap- 
plication, the method performed by the computer 
45 being characterised by the steps of: 

invoking a call on a program implementation 
code mechanism, the call invocation being 
made by a client application wherein the call in- 
so eludes a reference to the program implementa- 

tion code mechanism; 

using a stub program code mechanism which 
is related to the client application to receive the 
call invocation, wherein the stub program code 
55 mechanism has no knowledge of a format re- 

quired for marshaling data provided by the cli- 
ent application in connection with the call invo- 
cation; 
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acterised by: 

a first computer readable program code mech- 
anism configured to comprise an ORB-inde- 
5 pendent layer (69) of code mechanisms includ- 

ing client applications (112) and related stub 
program code mechanisms (114); and 
a second computer readable program code 
mechanism configured to comprise an ORB de- 
10 pendent layer (61) of code mechanisms cou- 

pled to the ORB independent layer (69), the 
ORB dependent layer comprising program 
code mechanisms which are ORB-specific and 
which are configured to generate a marshal 
15 code mechanism (210) to marshal data in an 

ORB required format and program code mech- 
anisms (1 1 6) configured to use a specific net- 
work protocol code whereby a program appli- 
cation code mechanism from the ORB inde- 
20 pendent layer can invoke a call on a remote im- 

plementation program code mechanism (120) 
and the ORB-specific program code mecha- 
nisms in the ORB dependent layer will deter- 
mine an appropriate marshal code mechanism 
25 to marshal data in an ORB required format, 

thereby providing a computer system capable 
of communicating with a multiplicity of ORBs 
wherein each ORB requires data to be in a spe- 
cific format. 



17 

calling a first specific program code mechanism 
(21 2) by the stub program code mechanism, re- 
questing the first specific program code mech- 
anism (212) to provide a MarshalBuffer code 
mechanism (21 0) that knows how to format da- 
ta provided by the client application in connec- 
tion with the call invocation; 
marshaling the data provided by the client ap- 
plication in connection with the call invocation, 
the marshaling being done by the stub program 
code mechanism using the MarshalBuffer code 
mechanism; and 

sending the call invocation to a server (118) 
containing the program implementation code 
mechanism which is the target of the call. 

7. The method described in claim 6, comprising the 
additional step of unmarshaling (21 6) results from 
the MarshalBuffer, the results supplied by the pro- 
gram implementation code mechanism which was 
called by the invocation. 

8. The method described in claim 6 or 7, wherein the 
first specific program code mechanism (212) called 
by the stub program code mechanism is an Object 
Request Broker (ORB) specific code mechanism. 

9. The method described in claim 6,7 or 8, wherein the 
stub program code mechanism which calls the ORB 
specific code mechanism (212) has no knowledge 
of the ORB which will process the call. 

10. The method described in claim 6, 7, 8 or 9, wherein 
the Object Request Broker (ORB) is an Object Man- 
agement Group (OMG) Common Object Request 
Broker (CORBA) compliant ORB. 

1 1 . The method of claim 6, 7, 8, 9 or 1 0, comprising the 
additional steps of: 

receiving an object invocation from a remote 
computer system (110) by a server-side ORB 
dependent code mechanism (120); and 
issuing a call into an ORB independent server 
application (214), the call made by the server- 
side ORB dependent code mechanism which 
passes in a MarshalBuffer that allows the serv- 
er application to unmarshat arguments and 
marshal results without having to know which 
ORB a call came from. 

12. A computer program product comprising a compu- 
ter system usable storage medium (9) having com- 
puter readable code embodied therein for causing 
a computer system to process program code mech- 
anism invocations which are directed to one of a 
multiplicity of remote Object Request brokers 
(ORBs), the computer program product being char- 



1 3. A computer product as defined in claim 1 2, wherein 
the ORB independent layer (69) of code mecha- 
nisms including program applications (112) and re- 
lated stubs (114) comprise object applications and 

35 related stubs. 

14. A computer program product as defined in claim 1 2 
or 1 3, wherein the marshal code mechanism to mar- 
shal data in an ORB required format which is locat- 

40 ed in the ORB-dependent layer (61 ) is a Marshal- 
Buffer Object (210) configured to execute opera- 
tions to marshal data in an ORB specific format. 

1 5. A computer program product as defined in claim 1 2 , 
45 13 or 14, wherein the program code mechanism 

configured to use a specific network protocol code 
(116) which is located in the ORB-dependent layer 
(61) is configured to use a network protocol code 
mechanism seleced from a group consisting of 
so Spring network protocol code and DOE network 
protocol code. 

1 6. A computer program product as defined in claim 1 2, 
1 3, 1 4 or 1 5, wherein the marshal code mechanism 

55 to marshal data in an ORB required format which is 
located in the ORB- dependent layer (61) is also 
configured to unmarshal results returned to It. 
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PatentansprOche 4. 

1. Computersystem mit einem Prozessor (3), einem 
Speicher (4), einem Anzeigegerat (6), einem Ein- 
Ausgabegerat (2) und einem Betriebssystem (OS) 5 
zum Verarbeiten von Aufrufen von Programmcode- 
mechanismen (10), die an eine Vielzahl von ortsfer- 
nen Object Request Brokern (ORBs) gerichtet sind, 
dadurch gekennzeichnet, dass das Computersy- 
stem femer folgendes umfasst: 10 

eine ORB-unabhangige Schicht von Codeme- 
chanismen (69) einschlieBlich Programman- 
wendungen und zugehorigen Stubs; und 
eine ORB-abhangige Schicht von Codemecha- is 
nismen (61), die mit der ORB-unabhangigen 
Schicht gekoppett ist, wobei die ORB-abhangi- 
ge Schicht folgendes umfasst: 

Programmcodemechanismen, die ORB- 20 
spezifisch (212) und so konfiguriert sind, 
dass sie einen Marshal-Codemechanis- 5. 
mus (210) zum Marshalieren (Einsortie- 
ren) von Daten jn einem von dem ORB be- 
notigten Fomiat erzeugen, und 25 
Programmcodemechanismen, die so kon- 6. 
figuriert sind, dass sie einen spezifischen 
Netzwerkprotokollcode (116) verwenden, 
so dass ein 

Programmanwendungscode-Mechanis- 30 
mus von der ORB-unabhangigen Schicht 
einen Aufruf an einen ortsfemen Imple- 
mentationsprogrammcode-Mechanismus 
einleiten kann, und die ORB-spezifischen 
Programmcodemechanismen in der ORB- 35 
abhangigen Schicht (61) einen geeigneten 
Marshal-Codemechanismus ermrtteln, um 
Daten in einem vorn ORB benotigten For- 
mat zu marschalieren; 

so dass ein Computersystem entsteht, das *o 
mit einer Vielzahl von ORBs kommunizie- 
ren kann, wobei jeder ORB ein spezielles 
Datenf ormat verlangt. 

2. Computersystem nach Anspruch 1, bei dem die 45 
ORB-unabhangige Schicht von Codemechanismen 
(69) mit Programmanwendungen und zugehorigen 
Stubs Objektanwendungen und zugehorige Stubs 
umfassen. 

50 

3. Computersystem nach Anspruch 1 Oder 2, bei dem 
der Marshal-Codemechanismus (210) zum Mar- 
shalieren von Daten in einem vom ORB benotigten 
Format, der sich in der ORB-abhangigen Schicht 
(61) befindet, ein MarshalBuffer-Objekt ist, das so ss 
konfiguriert ist, dass es Vorgange zum Marshalie- 
ren von Daten in einem ORB-spezifischen Format 
ausfuhrt. 



Computersystem nach Anspruch 1 , 2 Oder 3, bei 
dem der ProgrammcodeMechanismus, der so kon- 
figuriert ist, dass er einen spezifischen Netzwerk- 
protokollcode (116) verwendet, mit einem Server- 
computer (118) kommuniziert, der folgendes um- 
fasst: 

einen Empfangsprogrammcode-Mechanismus 
(120), der ORB-abhangigen Code umfasst, der 
so konfiguriert ist, dass er einen Objektaufruf 
von einem ortsfernen Computersystem (110) 
empfangt; und 

eine ORB-unabhangige Serveranwendung, so 
dass der Empfangsprogrammcode-Mechanis- 
mus in die ORB-unabhangige Serveranwen- 
dung (214) hineinruft und einen MarshalBuffer 
einbringt, so dass die Serveranwendung Argu- 
mente zuruckmarshalieren (aussortieren) und 
Ergebnisse marshalieren kann, ohne wissen zu 
mussen, von welchem ORB ein Anruf stammte. 

Computersystem nach Anspruch 1 , 2, 3 oder4, bei 
dem die ORB-abhangige Schicht (61) auch von der 
Betriebssystem -Schicht (OS) unabhangig ist. 

Verfahren zum Betreiben eines Computersystems 
mit einem Prozessor (3), einem Speicher (4), einem 
Anzeigegerat (6), einem Ein-Ausgabemechanis- 
mus (2), einem Betriebssystem und wenigstens ei- 
nem Client-Anwenderprogramm (112), einem oder 
mehreren Stub-Programmen (114) in Bezug auf die 
Client-Anwendung, wobei das mit dem Computer 
durchgefuhrte Verfahren durch die folgenden 
Schritte gekennzeichnet ist: 

Einleiten eines Aufrufs an einen Programmim- 
plementationscode-Mechanismus, wobei der 
Aufruf durch eine Client-Anwendung erfolgt, 
wobei der Aufruf eine Referenz auf den Pro- 
grammimplementationscode-Mechanismus 
beinhaltet; 

Verwenden eines Stubprogrammcode-Mecha- 
nismus, der sich auf die Client-Anwendung 
zum Empf angen des Aufrufs bezieht, wobei der 
Stubprogrammcode-Mechanismus das Format 
nicht kennt, das zum Marshalieren von Daten 
benotigt wird, die von der Client-Anwendung in 
Verbindung mit der Aufrufeinlertung bereitge- 
stelft werden; 

Aufrufen eines ersten spezifischen Programm- 
codemechanismus (212) durch den Stubpro- 
grammcode-Mechanismus, Anfordem des er- 
sten spezifischen Programmcodemechanis- 
mus (212) zur Bereitsteflung eines Marshal Buf - 
fer-Codemechanismus (210), der weiB, wie 
von der Client-Anwendung berertgestellte Da- 
ten in Verbindung mit dem Aufruf formatiert 
werden; 
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Marshalieren der von der Client-Anwendung 
bereitgestellten Daten in Verbindung mit dem 
Aufruf, wobei die Marshalierung vom Stubpro- 
grammcode-Mechanismus mit Hilfe des Mar- 
shalBuffer-Codemechanismus erfolgt; und s 
Senden des Aufruf s zu einem Server (118), der 
den Programmimplementationscode-Mecha- 
nismus enthatt, der das Ziel des Rufs ist. 

7. Verfahren nach Anspruch 6, umfassend den zu- 10 
satzlichen Schritt des Zuruckmarshalierens (216) 
von Ergebnissen vom Marshal Buffer, wobei die Er- 
gebnisse vom Programmimplementationscode- 
Mechanismus geliefert werden, der mit dem Aufruf 
gerufen wurde. 15 

8. Verfahren nach Anspruch 6 Oder 7, bei dem der er- 
ste spezifische Prog rammcode Mechanism us 
(212), der vom Stubprogrammcode-Mechanismus 
gerufen wurde, ein fur einen Object Request Broker 20 
(ORB) spezifischer Codemechanismus ist. 

9. Verfahren nach Anspruch 6, 7 oder 8, bei dem der 
Stubprogrammcode-Mechanismus, der den ORB- 
spezifischen Codemechanismus (212) ruft, den 25 
ORB nicht kennt, der den Ruf verarbeitet. 

10. Verfahren nach Anspruch 6, 7, 8 Oder 9, bei dem 
der Objekt Request Broker (ORB) ein ORB ist, der 

mit einem Common Object Request Broker (COR- 30 
BA) gemaB der Object Management Group (OMG) 
kompatibel ist. 

1 1 . Verfahren nach Anspruch 6, 7, 8, 9 oder 1 0, umfas- 
send die folgenden zusatziichen Schritte: 35 

Empfangen eines Objektaufrufs von einem 
ortsfernen Computersystem (110) auf einem 
serverseitigen ORB-abhangigen Codemecha- 
nismus (120); und 40 
Ausgeben eines Rufs in eine ORB-unabhangi- 
ge Serveranwendung (214), wobei der Ruf 
durch den serverseitigen ORB-abhangigen Co- 
demechanismus erfolgt, der einen MarshalBuf- 
fer einbringt, der es zulasst, dass die Server- 45 
anwendung Argumente zuruckmarshaliert und 
Ergebnisse marsh altert, ohne wissen zu mus- 
sen, von welchem ORB ein Ruf stammt. 

12. Computerprogrammprodukt, umfassend ein in ei- so 
nem Computersystem benutzbares Speichermedi- 

um (9), in dem rechnerlesbarer Code eingebettet 
ist, mit dem veranlasst werden kann, dass ein Com- 
putersystem Programmcodemechanismus-Aufrufe 
verarbeitet; die an einen aus einer Vielzahl von orts- 55 
fernen Object Request Brokern (ORBs) gerichtet 
sind, wobei das Computerprogrammprodukt ge- 
kennzeichnet ist durch: 



einen ersten rechnerlesbaren Programmcode- 
mechanismus, der so konfiguriert ist, dass er 
eine ORB-unabhangige Schicht (69) von Code- 
mechanismen umfasst, einschlieBlich Client- 
Anwendungen (1 1 2) und zugehorigen Stubpro- 
grammcode-Mechanismen (114); und 
einen zweiten rechnerlesbaren Programm- 
codemechanismus, der so konfiguriert ist, dass 
er eine ORB-abhangige Schicht (61) von Co- 
demechanismen umfasst, die mit der ORB-un- 
abhangigen Schicht (69) gekoppelt sind, wobei 
die ORB-abhangige Schicht Programmcode- 
mechanismen umfasst, die ORB-spezifisch 
und so konfiguriert sind, dass sie einen Mar- 
shal-Codemechanismus (210) zum Marshalie- 
ren von Daten in einem vom ORB benotigten 
Format erzeugen, und Programmcodemecha- 
nismen (116), die so konfiguriert sind, dass sie 
einen spezifischen Netzwerkprotokollcode be- 
nutzen, so dass ein Programmanwendungsco- 
de-Mechanismus von der ORB-unabhangigen 
Schicht einen Ruf auf einem ortsfernen 
Implementationsprogrammcodemechanismus 
(120) einleiten kann, unddieORB-spezifischen 
Programmcodemechanismen in der ORB-ab- 
hangigen Schicht einen geeigneten Marshal- 
Codemechanismus zum Marshalieren von Da- 
ten in einem vom ORB benotigten Format be- 
stimmen, so dass ein Computersystem bereit- 
gestellt wird, das in der Lage ist, m it einer Viel- 
zahl von ORBs zu kommunizieren, wobei jeder 
ORB Daten in einem bestimmten Format ver- 
langt. 

13. Computerprodukt nach Anspruch 12, bei dem die 
ORB-unabhangige Schicht (69) von Codemecha- 
nismen mit Programmanwendungen (112) und zu- 
gehorigen Stubs (114) Objektanwendungen und 
zugehorige Stubs umfassen. 

14. Computerprogrammprodukt nach Anspruch 12 
oder 13, bei dem der Marshal-Codemechanismus 
zum Marshalieren von Daten in einem vom ORB be- 
notigten Format, der sich in der ORB-abhangigen 
Schicht (61) befindet, ein MarshalBuffer Object 
(21 0) ist, das so konfiguriert ist, dass es Vorgange 
zum Marshalieren von Daten in einem ORB-spezi- 
fischen Format ausfuhrt 

15. Computerprogrammprodukt nach Anspruch 12, 13 
oder 1 4, bei dem der Programmcodemechanismus, 
der so konfiguriert ist, dass er einen spezifischen 
Netzwerkprotokollcode (116) benutzt, der sich in 
der ORB-abhangigen Schicht (61 ) befindet, so kon- 
figuriert ist, dass er einen Netzwerkprotokollcode- 
Mechanismus benutzt, derausgewahlt ist aus einer 
Gruppe bestehend aus Spring-Netzwerkprotokoll- 
code und DOE-Netzwerkprotokollcode. 
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ORB de mecanismes de code (69) incluant des ap- 
plications de programmation et des souches asso- 
ciees comprennent des applications objets et sou- 
ches associees. 

5 

3. Systeme d'ordinateur tel que defini dans la reven- 
dication 1 ou 2, dans lequel le mecanisme de code 
d'assemblage (21 0) pour assembler des donnees 
dans un format requis par un ORB qui se trouve 
10 dans la couche dependante des ORB (61) est un 
MarshalBuffer Object configure pour executer des 
operations pour assembler des donnees dans un 
format specif ique a un ORB. 

15 4. Systeme d'ordinateur tel que defini dans la reven- 
dication 1 , 2 ou 3, dans lequei le mecanisme de co- 
de de programmation configure pour utiliser un co- 
de specifique de protocole reseau (116) communi- 
que avec un ordinateur serveur (118) comprenant: 

20 

un mecanisme de code de programmation re- 
cepteur (120) comprenant un code dependant 
des ORB configure pour recevoir une invoca- 
tion d'objet d'un systeme d'ordinateur a distan- 

25 ce(110);et 

une application serveur independante des 
ORB par laquetle le mecanisme de code de 
programmation recepteur appelle I'application 
serveur independante des ORB (214), passant 

30 dans un MarshalBuffer qui autorise ('applica- 

tion serveur a disassembler les arguments et 
a assembler les resultats sans avoir a savoir de 
quel ORB un appel est venu. 



16. Computerprogrammprodukt nach Anspruch 12, 13, 
14 oder 15, bei dem der Marshal-Codemechanis- 
mus zum Marshalieren von Daten in einem vom 
ORB benotigten Format, der sich in der ORB-ab- 
hangigen Schicht (61) befindet, ebenfalls konfigu- 
riert ist, um an ihn zuruckgegebene Ergebnisse zu- 
ruckzumarshalieren. 



Revendications 

1 . Systeme d'ordinateur ayant un processeur (3), une 
memoire (4), un dispositif d'affichage (6), un dispo- 
sitif d'entree/sortie (2), et un systeme d'exploitation 
(OS) pour traiter des invocations de mecanismes 
(10) de code de programmation qui sont orientees 
vers I'un d'une multiplicite d'Object Request Bro- 
kers (Courtiers de Requetes) (ORB) a distance, ca- 
racterise en ce que le systeme d'ordinateur com- 
prend en outre : 

une couche independante des ORB de meca- 
nismes de code (69) incluant des applications 
de programmation et des souches associees; 
et 

une couche dependante des ORB de mecanis- 
mes de code (61), couplee a la couche inde- 
pendante des ORB, la couche dependante des 
ORB comprenant 

des mecanismes de code de programma- 
tion qui sont specif iques aux ORB (212) et 
qui sont configures pourg6nerer un meca- 
nisme de code d'assemblage (210) pour 
assembler des donnees dans un format re- 
quis par un ORB, et 

des mecanismes de code de programma- 
tion configures pour utiliser un code speci- 
fique de protocole reseau (116) par les- 
quels un mecanisme de code d'application 
de programmation de la couche indepen- 
dante des ORB peut invoquer un appel sur 
un mecanisme de code de programme 
d'implementation a distance et les meca- 
nismes de code de programmation speci- 
f iques aux ORB dans la couche dependan- 
te des ORB (61) determineront un meca- 
nisme de code d'assemblage approprie 
pour assembler des donnees dans un for- 
mat requis par un ORB; 
foumissant ainsi un systeme d'ordinateur 
capable de communiquer avec une multi- 
plicite d'ORB dans lequel chaque ORB exi- 
ge que les donnees soient dans un format 
specifique. 

2. Systeme d'ordinateur tel que defini dans la reven- 
dication 1 , dans lequel la couche independante des 



35 5. Systeme d'ordinateur tel que de>fini dans la reven- 
dication 1 , 2, 3 ou 4, dans lequel la couche depen- 
dante des ORB (61) est aussi independante de la 
couche du systeme d'exploitation (OS). 



40 6. Methode d'exploitation d'un systeme ordinateur 
ayant un processeur (3), une memoire (4), un affi- 
chage (6), un mecanisme d'entree/sortie (2), un 
systeme d'exploitation et au moins un programme 
d'application cliente (1 1 2), un ou plusieurs program- 

45 mes souches (114) associes a ('application cliente, 
la methode executee par ('ordinateur 6tant carac- 
terisee par les etapes consistant a : 

invoquer un appel sur un mecanisme de code 
so d'implementation de programme, ('invocation 

de I'appel etant f aite par une application cliente 
ou I'appel inclut une reference au mecanisme 
de code d'implementation de programme; 
utiliser un mecanisme de code de programme 
55 souche qui est associg a I'application cliente 

pour recevoir revocation d'appel, ou le meca- 
nisme de code de programme souche n'a aucu- 
ne connaissance d'un format requis pour as- 
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sembler les donnees fournies par Papplication 
cliente en rapport a I' invocation de I'appel; 
appeler un premier mecanisme de code speci- 
fique de programmation (212) par le mecanis- 
me de code de programme souche, demandant 5 
que le premier mecanisme de code specifique 
de programmation (212) fournisse un mecanis- 
me de code MarshalBuffer (210) qui sait com- 
ment formater les donnees fournies par I'appli- 
cation cliente en rapport avec invocation d'ap- io 
pel; 

assembler les donnees fournies par Implica- 
tion cliente en rapport avec invocation d'appel, 
I'assemblage etant fait par le mecanisme de co- 
de de programme souche en utilisant !e meca- is 
nisme de code de MarshalBuffer; et 
envoyer I'invocation d'appel a un serveur (118) 
contenant le mecanisme de code d'implemen- 
tation de programme qui est la cible de I'appel. 

20 

7. Methode decrite dans la revendication 6, compre- 
nant I'etape additionnelfe consistant a disassem- 
bler (216) les resuttats du MarshalBuffer, les resul- 
tats fournis par le mecanisme de code d'implemen- 
tation de programme qui a ete appele par I'invoca- 25 
tion. 



9. Methode decrite dans la revendication 6, 7 ou 8, 
dans laquelle le mecanisme de code de programme 
souche qui appelle le mecanisme de code specifi- 
que a un ORB (212) n'a aucune connaissance de 
I'ORB qui traitera I'appel. 

10. Methode decrite dans la revendication 6, 7, 8 ou 9, 
dans laquelle I'Object Request Broker (ORB) est un 
ORB conforme au Common Object Request Broker 
(CORBA) du Object Management Group (OMG). 

11. Methode de la revendication 6, 7, 8, 9 ou 10, com- 
prenant les etapes supplementaires consistant a : 

recevoir un invocation d'objet d'un system e 
d'ordinateur a distance (110) par un mecanis- 
me de code dependant de I'ORB cote serveur 
(120); et 

emettre un appel a une application serveur in- 
dependante de I'ORB (214), I'appel fait par le 
mecanisme de code dependant de I'ORB cote 
serveur qui passe dans un MarshalBuffer qui 
autorise ('application serveur a disassembler 
les arguments et a assembler les resultats sans 



avoir a savoir de quel ORB un appel est venu. 

12. Produit de programme informatiquecomprenant un 
support de stockage utilisable par un systeme d'or- 
dinateur (9) ayant un code lisible par ordinateur in- 
corpore dans celui-ci pourfaire qu'un systeme d'or- 
dinateur traite des invocations de mecanismes de 
code de programmation qui sont orientees vers I'un 
d'une multiplicity d'Object Request Brokers (ORB) 
a distance, le produit de programme informatique 
etant caracterise par : 

un premier mecanisme de code de program- 
mation lisible par ordinateur configure pour 
comprendre une couch e independante des 
ORB (69) de mecanismes de code incluant des 
applications clientes (112) et des mecanismes 
de code de programmes souches associes 
(114); et 

un deuxieme mecanisme de code de program- 
mation lisible par ordinateur configure pour 
comprendre une couche dependante des ORB 
(61) de mecanismes de code couplee a la cou- 
che independante des ORB (69), la couche de- 
pendante des ORB comprenant des mecanis- 
mes de code de programmation qui sont spe- 
cifiques aux ORB et qui sont configures pour 
generer un mecanisme de code d'assemblage 
(21 0) pour assembler des donnees dans un for- 
mat requis par un ORB et des mecanismes de 
code de programmation (116) configures pour 
utiliser un code specifique de protocole reseau 
en vertu de quoi un mecanisme de code du- 
plication de programmation de la couche inde- 
pendante des ORB peut invoquer un appel sur 
un mecanisme de code de programme d'imple- 
mentation (120) a distance et les mecanismes 
de code de programmation specifiques aux 
ORB dans la couche dependante des ORB de- 
termineront un mecanisme de code d'assem- 
blage approprie pour assembler des donnees 
dans un format requis par un ORB, fournissant 
ainsi un systeme d'ordinateur capable de com- 
muniqueravec une multiplicity d'ORB dans le- 
quel chaque ORB exige que les donnees soient 
dans un format specifique. 

13. Produit informatique tel que defini dans la revendi- 
cation 12, dans lequel la couche independante des 
ORB (69) de mecanismes de code incluant des ap- 
plications de programmation (112) et des souches 
associees (114) comprennent des applications ob- 
jets et des souches associees. 

14. Produit de programme informatique tel que defini 
dans la revendication 12 ou 13, dans lequel le me- 
canisme de code d'assemblage pour assembler 
des donnees dans un format requis par un ORB qui 



8. Methode decrite dans la revendication 6 ou 7, dans 
laquelle le premier mecanisme de code specifique 
de programmation (212) appele par le mecanisme 30 
de code de programme souche est un mecanisme 
de code specifique a un Object Request Broker 
(ORB). 
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se trouve dans la couche dependante des ORB (61 ) 
est un Marshal Buffer Object (21 0) configure pour 
executer des operations pour assembler des don- 
nees dans un format specifique a un ORB. 

5 

15. Prodult de programme informatique tel que defini 
dans la revendication 12, 13 ou 14, dans lequel le 
mecanisme de code de programmatlon configure 
pour utiliser un code specifique de protocole reseau 
(116) qui se trouve dans la couche dependante des 10 
ORB (61 ) est configure pour utiliser un mecanisme 

de code de protocole reseau selectionn6 d'un grou- 
pe consistant en code de protocole reseau Spring 
et en code de protocole reseau DOE. 

15 

16. Produit de programme informatique tel que d6fini 
dans la revendication 12, 13, 14 ou 15, dans lequel 
le mecanisme de code d'assemblage pour assem- 
bler des donnees dans un format requis par un ORB 

qui se trouve dans la couche dependante des ORB 20 
(61) est aussi configure pour disassembler les re- 
sultats qui lui sont renvoyes. 
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// 

1 1 MorshallBuffer describes o set of arguments or results to or from 
/I on IDL coll 

// 

£ockoge OP; 

public interface MarsholBuffer { 

byte aetByte 0 throws CORBA.SystemException; 
byte fj getbytes (int len) throws CORBA-SystemException; 
short getShort 0 throws CORBA.SystemException; 
int getlnt 0 throws CORBA-SystemException; 
long getLong Q throws CORBA£ystem£xception; 
char getChor Q throws CORBA.SystemExceptton; 
chor u getChars (int ten) throws CORBA.5ystemException; 
boolean getBool Q throws CORBA.SystemException; 
String getString Q throws CORBA^ystemException; 
float getfloat 0 throws CORBASystem Exception; 
double getOouble 0 throws CORBASystem Exception; 
^ public OP.SequenceHeader getSequencePreomble 0 throws CORBA.System Exception; 

void putByte (byte X) throws CO RBA^ystern Exception; 
void putBytes fbyte x []) throws CORBASysternException; 
void putShort (short x) throws CORBA.SystemException; 
void putlnt (int x) throws CORBASystemException; 
void putLong flong x) throws CQRB\SystemException; 
void putChor (char x) throws CORBA.SystemException; 
void putChors fchor x f]) throws COR8A.SystemException; 
void putString (String x) throws CORBASystemException; 
void putBool (boolean x) throws CORBASystemException; 
void putfloat (float x) throws CORSkSystemException; 
void putOouble (double x) throws COR8A.System£xception; 
public void putSequencePreambte (int length) throws CORBA-System Exception; 

void putNutl 0 throws CORBA-System Exception; 
•►void unmarshaLobject (CORBA.CORBA_Object.ObJect ref) throws CORBA.SysternException; 

//Release means the MarsholBuffer can discard or recyde its contents, 
void release Q; 

//reset means that the marshal buffer should be put bock into the some 
//state as a newly constructed MarshalBufffer 
void reset Q throws CORBA-SystemException; 
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